-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TEP: Contract source registry #91
base: master
Are you sure you want to change the base?
Conversation
|
||
## sources.json | ||
|
||
JSON file provided by a specific **verifier** for a specific **contract code hash** containing the URLs of source-code files and verification attestations. Fields of this file include: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should also include the original signatures (which are done on the data
part of the json)
{
data: {
codeHash:...
},
sigs: [{sig: '...', pubKey: '...'}]
}
otherwise, the UI will not be able to display the signatures used to verify the contract.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's indeed nice to add here as well for UI purposes, but then it's a bit circular. Because the signature is over code hash + sources_json_url and the sources_json_url is derived from a hash over its data and the signature is in the data. Do you have any simple way to overcome this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if signatures are stored on chain within the source item contract?
Each signature is 512bit, so this would add another 2-3 cells (assuming 5 verifier multi sig threshold)
This has interesting implications in case we retire and replace one or more of the original verifying nodes, so it would be good to decide how clients should handle such case (i.e. that the public key used to sign can no longer be found in the verifier registry).
|
||
### Actions | ||
|
||
* `update_verifier(verifier_id, backend_endpoints, quorum_config)` - If the verifier does not exist, ensures it deposits the required amount and adds to the registry. Otherwise updates details in the registry. The address that sends this update message is stored in the registry as the admin address and only it can update. The quorum config contains the list of public keys and how many are needed for quorum. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There probably should be a public key (representing the verifier) sent with this op as well, so that future operations (update endpoints, remove verifier) for an existing verifier can be authorized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the simplest behavior is that the address that sends the update message is regarded as the admin address and only this address can update later. So if the admin is a wallet contract, it would send the internal message of the update and on the first update (insert) it would be set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes In general I think verifying the sender is more elegant ( and more gas and storage efficient than public key method and simpler to code )
Co-authored-by: Shahar Yakir <[email protected]>
Co-authored-by: Shahar Yakir <[email protected]>
|
||
## Verifier registry contract | ||
|
||
A smart contract deployed to TON mainnet that holds a mapping between a **verifier id** to the **verifier details** which include the list of backends, their public keys and quorum configuration. To prevent spam in this registry, we propose that each verifier will deposit in the contract a sum of 1,000-10,000 TON coin. This sum will be returned when the verifier unregisters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An interesting point was whether to tie the staking amount to a config param, in order to reflect changes in TON/USD price.
E.g. 10 * 1e9 * Gas price (currently 1,000) => 10K ton
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a good idea, since the contract is immutable without any special admin role, this can normalize the deposit size in case TON USD price changes significantly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool
LGFM, maybe just some possible generalizations - we want to have verifiable credentials in ton, and it's verifier is so similar to Verite and may just have the same infrastructure ready and then implement source code repository. |
Sure, great idea Source code uploaders in the first stage will be through web UI (drag and drop in your browser). We will launch an open source client like jetton.live that runs on GitHub Pages and later offer TF to host it on verifier.ton.org. I think command line tools like toncli and hardhat will come second. Source code verifiers - we are also planning to launch a significant decentralized verifier operated by Orbs Network (orbs.com). It will be executed by a quorum of 21 staked Orbs oracles. Source-code displayers, I think TonWhales explorer is here and I'll contact tonscan.org to join. I already talked about this general concept with them and they're waiting to see the widget that they should embed in their site so they can comment on it |
|
||
#### Actions | ||
|
||
* `update_sources(code_hash, verifier_id, sources_json_url, signatures)` - Verifies that the signatures match the verifier's quorum detailed under **verifier registry** and updates the **sources registry** with the url. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The signed data should include a measure of preventing replay attack, such as a valid_until
timestamp which can be verified as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ادم باش
Implementation for the sources registry contract can be found here: |
Implementation for the verifier registry contract was carried out via a ton footsteps grant: |
Okay
…On Wed, 27 Dec 2023 at 3:34 AM, hebosho911 ***@***.***> wrote:
—
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSVSHHH2XO26T5M6SBDYLPMRNAVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGA3TGMBYHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
What do I need to do now
…On Tue, 2 Jan 2024 at 6:37 PM, osas ehimen ***@***.***> wrote:
Okay
On Wed, 27 Dec 2023 at 3:34 AM, hebosho911 ***@***.***>
wrote:
> —
> Reply to this email directly, view it on GitHub
> <#91 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/A73LUSVSHHH2XO26T5M6SBDYLPMRNAVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGA3TGMBYHE>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
2 similar comments
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
What address is this
…On Fri, Aug 2, 2024 at 8:59 AM Antorhalder ***@***.***> wrote:
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx
—
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSQU7UBF6HU5K5HYH33ZPN7C5AVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVGM2TKNBXHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
UQD6Riw7pw8Vb4dnPj_qqJmtC822sVlLCN2yGdV5J78ADTuY
…On Fri, Aug 2, 2024 at 9:00 AM osas ehimen ***@***.***> wrote:
What address is this
On Fri, Aug 2, 2024 at 8:59 AM Antorhalder ***@***.***>
wrote:
> UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx
>
> —
> Reply to this email directly, view it on GitHub
> <#91 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/A73LUSQU7UBF6HU5K5HYH33ZPN7C5AVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVGM2TKNBXHE>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
UQD6Riw7pw8Vb4dnPj_qqJmtC822sVlLCN2yGdV5J78ADTuY
…On Sun, Jun 30, 2024 at 6:29 PM Lorik56 ***@***.***> wrote:
***@***.**** approved this pull request.
—
Reply to this email directly, view it on GitHub
<#91 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSR7LV4OS5U753HBZXDZKCBF7AVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNJQGIYDMMZXGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
UQD6Riw7pw8Vb4dnPj_qqJmtC822sVlLCN2yGdV5J78ADTuY
…On Tue, Apr 23, 2024 at 3:58 AM Hebosho911 ***@***.***> wrote:
***@***.**** approved this pull request.
#from github import Github
import os
def get_user_token():
# Generar un token único para el usuario actual
return os.urandom(16).hex()
def merge_pull_request(repo_name, pull_request_number):
# Obtener el token único del usuario
user_token = get_user_token()
# Inicializar el objeto Github con el token del usuario
g = Github(user_token)
try:
# Obtener el repositorio
repo = g.get_repo(repo_name)
# Obtener el pull request
pull_request = repo.get_pull(pull_request_number)
# Fusionar el pull request
pull_request.merge()
print("¡El pull request ha sido fusionado exitosamente!")
except Exception as e:
print(f"Error al fusionar el pull request: {e}")
Nombre del repositorio y número del pull request
repo_name = 'ton-blockchain/TEPs'
pull_request_number = 91
Fusionar el pull request
merge_pull_request(repo_name, pull_request_number)
—
Reply to this email directly, view it on GitHub
<#91 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSRY3E7AJTSN6T4O5L3Y6YIBPAVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMJWGUZDOMZUGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
1 similar comment
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
UQD6Riw7pw8Vb4dnPj_qqJmtC822sVlLCN2yGdV5J78ADTuY
…On Fri, Aug 2, 2024 at 9:05 AM Antorhalder ***@***.***> wrote:
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx
—
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A73LUSVTBK4O34YF4EF6AN3ZPN7ZBAVCNFSM6AAAAAAQI6N6AWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVGM3DKMZWGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
UQAL1divDXnelbf4kbFBrCrk3s7GRs_sRktVXsw0LzS1tRBA |
2 similar comments
UQAL1divDXnelbf4kbFBrCrk3s7GRs_sRktVXsw0LzS1tRBA |
UQAL1divDXnelbf4kbFBrCrk3s7GRs_sRktVXsw0LzS1tRBA |
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
2 similar comments
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
UQAutOwc-EVANIwf1MG2m_M0wsubYsZnwUvPMMCkI8a3fkQx |
|
||
## Verifier registry contract | ||
|
||
A smart contract deployed to TON mainnet that holds a mapping between a **verifier id** to the **verifier details** which include the list of backends, their public keys and quorum configuration. To prevent spam in this registry, we propose that each verifier will deposit in the contract a sum of 1,000-10,000 TON coin. This sum will be returned when the verifier unregisters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UQCWb4npmDTu3tkvQVHCDBpvDYSMLgyPV2Cvfxhpy3ucRHxo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How to earn ton and other coins please help any contract swap link
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How to start
This comment was marked as spam.
This comment was marked as spam.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UQBulKXWVFmcTBtf1XsxVA9pfXCzSyNG4mGPhUNJ4Qt6YHAq
This proposal defines decentralized infrastructure and an on-chain registry to store the source code for verified TON smart contracts.
The proposal also defines a simple permissionless protocol where community source code verifiers can register and publish signed attestations that they have indeed verified specific contracts.